In bug 1563415 we see some performance regressions from using customElements.setElementCreationCallback() to import our moz- UI widgets using ChromeUtils.importESModule(script, { global: "current" }) similarly to how the non-ESM widgets have been getting imported.

To work around this issue I propose that the SetElementCreationCallback handler be immediately invoked if there are candidate upgrade elements for the component, and defer setting the callback until the DOMContentLoaded event for our ESM based UI widgets.

I'm open to other potential solutions here, but figured I'd post what worked while debugging this issue.

When using SetElementCreationCallback during about:preferences load for
ESM based UI Widgets we are seeing a performance regression vs using
<script type="module"> on the page.

To work around this issue we can delay registering the callback until
the DOMContentLoaded event which improves performance, presumably due to
reduced thrashing from HTML parsing to JS parsing.

With that change however any components that were encountered before the
DOMContentLoaded event will not be loaded or upgraded until the next
time a component of that type is created.

This patch updates the SetElementCreationCallback function to
immediately invoke the callback if there are candidate elemments of that
type to upgrade.

https://hg.mozilla.org/mozilla-central/rev/97b477552580